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Tutorial  Goals 


After  completing  this  tutorial,  participants  will  be  able  to: 

•  Describe  common  Agile  myths  for  government  settings  and  their 
source 

•  Debunk  these  common  Agile  myths 

•  List  common  Agile  approaches  seen  in  government  settings 

•  Discuss  common  challenges  to  Agile  adoption  in  any  setting 

•  Discuss  challenges  to  Agile  adoption  particular  to  regulated  settings 
like  the  DoD 

•  Recognize  potential  Agile  variants  that  are/are  not  productive  in 
regulated  settings 
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Audience — Who  are  You? 


What  role  do  you 
have  in  software 
acquisition? 
Engineer 
Developer 
Project  Mgmt 
Budget  Staff 
Contracting  Staff 
Other? 
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Tutorial  Content 

Why  do  we  need  Agile  or  lean  software  methods  anyway? 

Key  Components  of  Agile  Development:  Agile  principles 

Top  10  Myths  of  Agile  in  DoD/government  settings 

Traditional  and  Agile  Acquisition  Life  Cycles:  Fixed  vs  evolving  vision 

Common  Agile  Methods:  One  size  does  not  fit  all 

Scrum:  The  most  adopted  Agile  method 

Scaling  Agile  Methods:  Going  beyond  the  team  level  methods 

Challenges  to  Agile  Adoption:  What’s  special  about  agile  adoption  in  the 
DoD? 

BONUS:  Gimmes  and  Gotchas  in  Agile  adoption  (time  permitting) 


_ —  Agile  Myths,  Picatinny  Arsenal 
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What  Else  do  You  Need  to  Learn? 


3— Break  into  pairs  and  discuss  what  one  thing  BEYOND  what  we've  said  will 
be  included  that  you  want  to  get  out  of  the  tutorial  (3  min) 

Instructor  will  solicit  answers  and  comment  on  what’s  in/what’s  out  of  scope  for 
this  tutorial. 


'to  educate." 
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Tutorial  Logistics 
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Course  Approach 


Exercises,  discussions,  presentations... 


=  Software  Engineering  Institute  Carnegie  Mellon  University 


Agile  Myths,  Picatinny  Arsenal 
Lapham,  Wrubel  Jan  2015 
©  2015  Carnegie  Mellon  University. 


Summary 


This  is  an  overview — we  will  touch  on  many  topics,  but  rarely  will  have 
time  to  go  into  depth 


We  will  do  our  best  to  integrate  your  learning  needs  into  our  plan 


We  welcome  your  sharing  your  experiences  with  Agile  -  if  we  cut  you 
short,  it’s  because  of  lack  of  time,  not  lack  of  interest 


_ —  Agile  Myths,  Picatinny  Arsenal 
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WHY  DO  WE  NEED  AGILE  SW 
DEVELOPMENT  METHODS 
ANYWAY? 
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DoD  Acquisition 
and  Innovation 


Many  regulated  environments, 
like  the  DoD,  NEED  innovation  • 
and  NEED  incremental 
improvements  to  their 
systems. 


New 

Mission 

Need 


Many  of  them  are  now  willing 
to  consider  changing  their 
approach  if  they  can  do  it 
without  getting  in  trouble 
with  their  governing  statutes 
and  regulations. 


Systems  and  Software  Engineering 
Expertise  and  Framework 


Balance  evolution  of 
user  needs  and 
developed  capabilities. 


I  Traditional  Approach 

/ 


New 

Mission 

Capability 


¥ 

o  -o 


Traditional  Approach 


Incremental  Approach 

- ► 

Time 


DoD/IC  for  intelligence 
community,  requirements, 
stakeholders,  needs, 
business  practices,  user 
test  and  evaluation 
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The  View  of  Our  Customers 


Traditional  Development 
Tempo 


Traditional  Acquisition/ 
Readiness  Tempo 


Traditional  Operations/ 
Demand  Tempo 
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Can  software  development  be  managed 
the  same  as  hardware  development? 


Hardware  Sys  Development  Software  Realities 

Assumptions 


Systems  can  be  decomposed  into  discrete, 
independent,  and  hierarchically-related 
components  (or  subsystems). 


•  Software  components  are  often  related  sets 
of  layered  functionality  (one  layer  is  not 
contained  inside  another  layer). 


Is  part  of:  Components  can  be  constructed 
and  integrated  with  minimal  effort  based  on 
the  original  decomposition. 

Quality  attributes  can  be  allocated  to 
specific  components. 


•  Is  used  by:  Interactions  of  the  components 
(not  the  decomposition)  must  be  managed. 

•  Quality  attributes  relate  to  composite 
interactions  (not  to  individual  components). 


Interfaces 

to 

capabilities 
provided  by 
a  layer 


Within  and 
outside  of  the 
system 

(e.g.,  LAN,  device 
drivers) 
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Some  Things  Are  Easier  in  Software 


METHODS  wei-CD/VC  CHAU&ihcSr 

REQUIREMENTS,  EVEN  LATTC  iw  ~D€ VEJ-QPlftE. N T 

^  W  \t  Ldur  ffrj\ 


+}*HT  ffrj 

vSe  **'S 
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Capabilities  delivered  Capabilities  delivered 


Both  Waterfall  (HW-centric)  and  Agile 
Development  (SW-centric)  Have  Risks 


M  ■ 

Agile  Development 

_ 

/ 

f 

] 

r 

J 

\ 

L id. 

Cost  of  over  analysis,  up-front  requirements, 
design  delays  capabilities  delivered,  creates 
missed  opportunities 


Assess  the  impact  of: 

•  delivered  capabilities 

•  cost  of  delay,  rework 
to  determine  efficient 

increments. 


m — s - 

1  rod  CPC  1  nj_ nnrirLO  chammo 


B 


egrated  Approach 


Accumulated  suboptimal  architecture,  lack  of 
communication  and  clear  requirements  impact 
capabilities  delivered.  The  consequences  are 
delays,  defects  and  inability  to  deliver 


ftatn  Jiaoli 


Ozkaya,  Ipek.  Internal  SEI  customer  presentation,  2012. 
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Historical  Reasons  SW  Acquisitions  Fail 


Top  10  Reasons 

Your  Perspective 

10.  Technology  used  is  new  to  the  organization 

9.  Software  issues  are  considered  too  late  in  the  system-development 
process 

8.  Inadequate  planning  and  estimating;  long  duration  programs 

7.  Size  matters  -  large  projects  get  into  trouble  more  frequently  than 
smaller  ones 

6.  Software  objectives/requirements  are  not  fully  understood  or  specified; 
they  change  frequently  (and  grow)  during  the  project;  growth  often 
uncontrolled/mismanaged 

5.  Inadequate  project  management  methodology 

4.  Inadequate  process  emphasis 

3.  Inadequate  contract  incentives  to  encourage  use  of  modern  software 
engineering  practices 

2.  Acquirers  and  developers  lack  experience  working  as  a  team 

1 .  Insufficient  senior  staff  and/or  inexperienced  software  engineering 
cadre 


Source:  Nielsen,  P.  Congressional  Testimony  July  9,  2009. 
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Summary 

No  single  engineering  life  cycle  or  acquisition  approach  is  perfect  “out  of 
the  box”  for  individual  acquisition  situations 

•  Understanding  the  range  of  acquisition  life  cycle  possibilities  is  a  key  to 
enabling  a  successful  acquisition  (using  Agile  or  other  approaches!) 

-  Recent  interim  DoD  5000.02  guidance  increases  the  explicitly-described 
variations  of  acquisition  life  cycles  available  to  software  -  good  news  for 
those  needing  to  use  Agile  methods 

Software  acquisitions  have  been  failing  for  decades1 

•  This  is  a  multi-factor  problem  with  lots  of  complexity 

-  Differences  in  what  works  for  hardware-centric  and  what  works  for 
software-centric  acquisitions  is  a  common  theme 

•  Some  of  the  top  failure  modes  have  been  mitigated  in  individual  instances  by 
robust  Agile  implementations 

-  Duplicating  their  success  means  understanding  Agile  methods  and  their 
implications  beyond  tutorial  level! 


7  See  SEI’s  “Acquisition  Dynamics”  research  for  other  causes  beyond  what  is  discussed  here  See  www.  sei.  emu,  edu/acguisition/research  for  more  details. 


KEY  COMPONENTS  OF  AGILE 
DEVELOPMENT 


_ —  Agile  Myths,  Picatinny  Arsenal 
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Agile  Manifesto-Foundation  of  Agile  Software 
Development 


Through  this  work  we  have  come  to  value: 

•  Individuals  and  interactions  over  processes  and 

tools 

•Working  software  over  comprehensive 
documentation 

•Customer  collaboration  over  contract  negotiation 
•Responding  to  change  over  following  a  plan 

That  is,  while  there  is  value  in  the  items  on  the 

right, 

we  value  the  items  on  the  left  more. 


http://www.agilemanifesto.org/ 


Common  myth: 

The  manifesto  is 
often  misinterpreted 
to  mean 

no  documentation, 
no  process,  and 
no  plan! 
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Agile  Principles  Accompanying  the  Manifesto  1  - 

All  are  important  aspects  of  building  an  agile  culture 

1.  Highest  priority  is  satisfy  the  customer  through  early  and  continuous 
delivery  of  software. 

2.  Welcome  changing  requirements,  even  late  in  development... 

3.  Deliver  working  software  frequently,  from  a  couple  of  weeks  to  a 
couple  of  months... 

4.  Business  people  and  developers  must  work  together  daily 
throughout  the  project. 

5.  Build  projects  around  motivated  individuals.  Provide  environment 
and  support  they  need . . . 

6.  The  most  efficient  and  effective  method  of  conveying  information  to 
and  within  a  development  team  is  face-to-face  conversation. 


_ —  Agile  Myths,  Picatinny  Arsenal 
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Agile  Principles  Accompanying  the  Manifesto  2  - 

All  are  important  aspects  of  building  an  agile  culture 

7.  Working  software  is  the  primary  measure  of  progress. 

8.  Agile  processes  promote  sustainable  development... a  constant 
pace  indefinitely. 

9.  Continuous  attention  to  technical  excellence  and  good  design 
enhances  agility. 

10.  Simplicity — the  art  of  maximizing  the  amount  of  work  not  done--is 
essential. 

11.  The  best  architectures,  requirements,  and  designs  emerge  from 
self-organizing  teams. 

12.  At  regular  intervals,  the  team  reflects  on  how  to  become  more 
effective,  then  tunes  and  adjusts  its  behavior  accordingly. 


Adapted  from  http://agilemanifesto.org/principles.html 
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Exercise 


5  Break  into  pairs  and  discuss  “What  myths  have  you  heard  related  to 
Agile  that  could  come  from  the  manifesto  or  principles?” 

Each  pair  provides  two  sticky  notes,  each  with  one  idea,  to  instructor's  flip 
chart 

Instructor  will  quickly  group  them  and  tell  group  which  ones  are  addressed 
in  this  tutorial  and  which  are  not. 
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Changing  the  Trade  Space 


Scope 


Value 


Quality 


Quality 


Cost 


Schedule 


Constraints 
(Scope,  Cost, 
Schedule) 


Adapted  from  Jim  Highsmith  (http://www.jimhighsmith.com/2010/11/14/beyond-scope-schedule-and-cost-the-agile- 
tri angle/). 
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Some  Common  Characteristics  of  Agile 
implementations 


Iterative  — elements  are  expected  to  move  from  skeletal  to  completely  fleshed 
out  over  time,  not  all  in  one  step 

Incremental  — delivery  doesn’t  occur  all  at  once 

Collaborative  — progress  is  expected  to  be  made  by  stakeholders  and  the 
development  team  working  collaboratively  throughout  the  development  time 
frame 

Parallel  — multiple  self-organizing,  cross-functional  teams  work  concurrently  on 
multiple  product  elements  (e.g.,  requirements,  architecture,  design,  and  the  like 
for  multiple  loosely  coupled  product  components) 

Dedicated  — team  members  are  allowed  to  focus  on  the  tasks  within  an 
iteration/release  as  opposed  to  multi-tasking  across  multiple  projects 

Time-boxed  — relatively  short-duration  development  cycles  that  permit 
changes  in  scope  rather  than  changes  in  delivery  time  frame 


Adapted  Nidiffer,  Miller,  &  Carney.  Potential  Use  of  Agile  Methods  in  Selected  DoD  Acquisitions:  Requirements  Development  &  Management,  SEI-2013- 
TN-006 
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Exercise 


->S*' 

Using  the  handout  provided,  follow  the  facilitator’s  instructions  carefully. 
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Summary 


The  key  to  successful  Agile  implementation  is  understanding  how  you 
will  instantiate  the  Agile  manifesto  and  principles 


When  using  Agile  methods,  the  trade  space  changes  -  from  fixed  vision 
and  evolving  time,  to  fixed  time  and  evolving  vision 


The  Agile  principles  have  implications  for  the  characteristics  of  the  life 
cycle  that  can  be  used 

•  But  there’s  still  more  than  one  valid  way  of  implementing  the  principles 
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(opinion  of  the  authors,  not  an  empirical  survey) 

TOP  10  AGILE  MYTHS  IN 
REGULATED  SETTINGS 


_ —  Agile  Myths,  Picatinny  Arsenal 

-^=-  Software  Engineering  Institute  Carnegie  Mellon  University  Lapham,  wmbei  Jan  2015  27 

*  ©  2015  Carnegie  Mellon  University. 


Which  myths  do  you  most  want  to  talk  about? 


Your  Vote 


Agile  is  a  fad — if  I  wait  long  enough,  it  will  go  away 


Agile  teams  don’t  document  anything 

Agile  is  “cowboy”  programming 

Agile  only  works  in  co-located  environments 

Agile  is  just  incremental,  or  spiral,  or  iterative, 

renamed 

Agile  won’t  “stick”  in  DoD/regulated  environments 

Agile  only  works  with  small  projects 

Agile  software  teams  can  succeed  in  a  vacuum 

You  must  choose  Agile  or  Waterfall — you  can’t  do 
both 

You  can’t  use  Earned  Value  Management  on  Agile 
Software  Developments 
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Myth:  Agile  software  teams  can  succeed  in  a 
vacuum 


V 
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Myth:  Agile  is  a  Fad. ..if  I  wait  long  enough,  it 
will  go  away... 


DoD  and  NDAA  documents  tend  to  suggest  that  DoD  IT  projects  follow 
Agile-like  processes  and  lifecycles 


Federal  working  groups/task  forces  in  place  to  support  these  directives 
(e.g.  Section  804  Task  Force)  [AFE2012] 


Government  is  looking  at  alternative  development  processes  to  enable 
earlier  delivery  of  capability  to  users. 


Interim  DoD  5000.02  guidance  include  hybrid  life  cycle  examples  that 
more  easily  accommodate  Agile  methods  implementation. 
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Myth:  You  Must  Choose  Agile  or  Waterfall  - 
you  can’t  do  both 

What  about  “water-scrum-fall”? 
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Myth:  Agile  only  works  for  small  projects.... 

Scaled  Agile  Framework"  Big  Picture  |  | 
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Myth:  Agile  is  just  incremental,  or  spiral,  or 
iterative,  renamed 
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Source:  Palmquist,  Steven;  Lapham,  Mary  Ann;  Garcia-Miller,  Suzanne;  Chick,  Timothy;  &  Ozkaya,  Ipek.  Parallel  Worlds:  Agile  and  Waterfall  Differences  and  Similarities 
(CMU/SEI-2013-TN-021).  Software  Engineering  Institute,  Carnegie  Mellon  University,  2013. 
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Myth:  Agile  Won’t  “Stick”  in  DoD  Environments 


It’s  a  Journey... Patriot  Excalibur  switched  to  Agile 
methods  in  2003  and  successfully  continues  today 


ilk  3°urncy  °f 


(**) 

>  o( 

}tnc*vU  +\vt  etoimi^c-n  raJau- 
in  tht  t«t  wiw<* 

IP 


A^o^*<i  YP  m  200^ 

O  rnorr  jME*:  I  ^  ^ 

.  „  \  20  m.  2C7, 

o  more  reVe^S*-  - - - 

o  more 
delivered 


Gut  l 


2007  Acyl^i^^- 

^ivc  **’1 

0*o  «**-*»-*  «*  b,'j‘  r 

o’WrWaV*  WVr  ■* 


ZOOS  Aa.Ic  &<>lL 
.  £„»«;-  5c’"'"  r"odcl 

~  Trvkr"^  +ta"is 

O  ft*'  5WE’ 

o  KM"  ^  ^ 

*  rScKSV; 

2^9/lG  Expansion 

°  D*«^ivJ  (Vfrotttd'fc’  (oQ(j  adopfcrj 

r»  Incrravd  toT^J  ~  lC/°  ^ 

0  ArclaikctuK  =$■  SC»A 
°  diftnibwVd  4re>l/vl 

Aficfc-J  ov/Mrtjrk'-j  -ks+v^  4r XjM\ 

7£\U  D>f  faulty  Scaling 

c  7w«<  -kd  ««**  ef 

ft  rkrat'o*^ 

o  ka**£  Ski/  very  WKkprde«F 
omtfod(*<(rd  -teciamcal  d«Vjt 

-*kvt  h«i(4  up 


From  SEI  Agile  Collaboration  Group  Colloquium,  March  2013.  Used  with  permission. 
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Myth:  Agile  Only  Works  in  Co-Located 
Environments 


□  Got  Better  □  No  Benefit  □  Got  Worse 


Ability  to  manage  changing  priorities 
Increased  productivity 
Improved  project  visibility 
Improved  team  morale 
Enhanced  software  quality 
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Myth:  Agile  is  “cowboy  programming” 

^r~  Break  into  pairs  and  review  the  Agile  principles  --  which  of  those 
principles  supports  “cowboy  programming”  as  described  below? 
(description  taken  from  “10  types  of  programmers  you'll  encounter  in  the 
field”  by  Justin  James) 

Be  prepared  to  discuss  your  thoughts  with  the  larger  class. 


The  Code  Cowboy 

The  Code  Cowboy  is  a  force  of  nature  that  cannot  be  stopped.  He  or  she  is  almost  always  a  great  programmer  and  can 
do  work  two  or  three  times  faster  than  anyone  else.  The  problem  is,  at  least  half  of  that  speed  comes  by  cutting  corners. 
The  Code  Cowboy  feels  that  checking  code  into  source  control  takes  too  long,  storing  configuration  data  outside  of  the 
code  itself  takes  too  long,  communicating  with  anyone  else  takes  too  long...  you  get  the  idea. 

The  Code  Cowboy's  code  is  a  spaghetti  code  mess,  because  he  or  she  was  working  so  quickly  that  the  needed 
refactoring  never  happened.  Chances  are,  seven  pages'  worth  of  core  functionality  looks  like  the  "don't  do  this"  example 
of  a  programming  textbook,  but  it  magically  works.  The  Code  Cowboy  definitely  does  not  play  well  with  others.  And  if  you 
put  two  Code  Cowboys  on  the  same  project,  it  is  guaranteed  to  fail,  as  they  trample  on  each  other's  changes  and  shoot 
each  other  in  the  foot. 

Put  a  Code  Cowboy  on  a  project  where  hitting  the  deadline  is  more  important  than  doing  it  right,  and  the  code  will  be 
done  just  before  deadline  every  time.  The  Code  Cowboy  is  really  just  a  loud,  boisterous  version  of  The  Ninja.  While  The 
Ninja  executes  with  surgical  precision,  The  Code  Cowboy  is  a  raging  bull  and  will  gore  anything  that  gets  in  the  way. 


Source:  http://www.  techrepublic.  com/blog/1 0-things/1 0-types-of-programmers-youll-encounter-in-the-field/262/ 
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Myth:  Agile  Teams  don’t  Document  Anything 
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Myth:  You  Can’t  Use  Earned  Value  Management 
with  Agile  Software  Development 
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“Agile  EVM”  is  successfully 
used  in  multiple  environments, 
including  DoD  programs.1 


^tart  with  “Agile  EVM  in  Scrum  Projects”  from  AGILE  2006  to  get  started  learning  about  Agile  &  EVM. 
http://www.computer.org/csdl/proceedinqs/aqile/2006/2562/00/25620007-abs.html 
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Top  10  Reasons 

Your  Perspective 

10.  Technology  used  is  new  to  the  organization 

9.  Software  issues  are  considered  too  late  in  the  system-development 
process 

8.  Inadequate  planning  and  estimating;  long  duration  programs 

7.  Size  matters  -  large  projects  get  into  trouble  more  frequently  than 
smaller  ones 

6.  Software  objectives/requirements  are  not  fully  understood  or  specified; 
they  change  frequently  (and  grow)  during  the  project;  growth  often 
uncontrolled/mismanaged 

5.  Inadequate  project  management  methodology 

4.  Inadequate  process  emphasis 

3.  Inadequate  contract  incentives  to  encourage  use  of  modern  software 
engineering  practices 

2.  Acquirers  and  developers  lack  experience  working  as  a  team 

1 .  Insufficient  senior  staff  and/or  inexperienced  software  engineering 
cadre 

Source:  Nielsen,  P.  Congressional  Testimony  July  9,  2009. 

Break  into  pairs  and  discuss  how  following  Agile  principles  might 
mitigate  these  historical  SW  acquisition  failures? 

Be  prepared  to  discuss  your  thoughts  with  the  larger  class. 
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Summary 


Like  all  myths,  Agile  myths  usually  are  based  on  some  actual 
experience 

•  Sometimes  anomalous 

•  Often  happens  when  teams  who  are  trying  to  mimic  Agile  practices  without 
understanding  Agile  principles  fail  in  some  way 

We  have  seen  counterexamples  FOR  ALL  THESE  MYTHS  in  DoD  and 
other  government  settings 

•  Agile  isn’t  always  the  answer  to  a  software  acquisition’s  problems,  but  these 
myths  shouldn’t  be  a  reason  to  avoid  it 

There  are  lots  of  other  lists  of  Agile  myths  (see  References  at  the  end  of 
the  tutorial) 

•  We  have  focused  on  ones  that  we  commonly  hear  about  related  to 
government  settings 
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TRADITIONAL  &  AGILE 
ACQUISITION  LIFE  CYCLES 
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Overarching  Framework  for  System  Acquisition 


QAU 


The  Defense  Acquisition  Management  System 
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down ”  have  more 
explicit  variety  in 
the  new  DoD 
5000.02 
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January  2015. 
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New  Life  Cycle  Descriptions  in  DoD  5000.02 

Figure  8.  Model  6:  Hybrid  Program  B  (Software  Dominant) 


Figure  5.  Model  3;  Incrementally  Deployed  Software  Intensive  Program 
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http://www.acq.osd.mil/docs/500002p.pdf 

issued  Jan  7,  2015 
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The 
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One  View  of  Large  Scale  Agile  Development 
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Source:  Palmquist,  Steve,  et  at.  Parallel  Worlds: 
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Three  Commercial  Approaches  to  Agile  at  Scale 

Scaled  Agile  Framework  Big  Picture  ^  iCo,Llc^^,n,Ya,lCa°»! 
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Reconciling  Traditional  and  Agile  Life  Cycle 
Viewpoints 


Traditional  at  its  Worst 

Agile  at  its  Best 

Plan  the  work — especially  the  budget, 
schedule,  and  deliverables — to  the  maximum 
extent  possible  before  beginning  any  design 
or  code. 

•  Near-term  plans  contain  more  detail,  while  plans  further  out  on  the  time 
horizon  contain  fewer  details. 

•  The  overall  vision  is  broken  down  into  a  roadmap,  which  is  further  broken 
down  into  release  plans,  which  are  further  broken  down  into  sprint  or 
iteration  plans,  which  are  further  broken  down  into  daily  plans. 

•  Requirements  are  prioritized. 

•  Cost  and  schedule  estimates  are  prepared  for  each  capability  at  a  high 
level.  Relative  estimation  versus  absolute  estimation  is  employed. 

•  Frequent  planning  sessions  (at  the  beginning  of  each  iteration)  result  in 
detailed,  high-fidelity  plans. 

•  Risks  are  assessed  and  risk  mitigation  influences  planning. 

Lock  down  requirements  to  prevent  gold- 
plating  and  scope  creep. 

•  No  requirements  can  be  added  to  an  iteration  once  it  has  started. 

•  New  requirements  are  evaluated  by  the  stakeholders  and  prioritized  thus 
preventing  gold-plating  and  scope  creep. 

Institute  multiple  reviews  to  provide  senior 
leadership  oversight  as  well  as  to  serve  as 
gates  for  continued  work. 

•  The  customer  is  involved  in  all  aspects  of  planning  and  testing.  Customer 
(in  the  form  of  the  product  owner)  is  involved  daily. 

•  There  are  reviews  at  the  end  of  each  iteration  that  serve  as  gates  to 
further  work. 

Move  forward  in  a  step-by-step,  sequential 
manner  and  only  when  all  parts  of  the 
previous  steps  were  complete. 

•  The  code  base  is  integrated  and  tested  daily. 

•  The  code  base  must  pass  all  tests  before  and  after  integration. 

Regression  testing  is  typically  done  each  night. 

Capture  all  details  with  extensive 
documentation. 

•  There  is  an  overall  plan. 

•  There  are  requirements  descriptions. 

•  There  are  cost  and  schedule  estimates. 

•  There  are  risk  assessments. 

•  There  is  training  material  (as  appropriate). 

•  There  is  documentation  (as  appropriate). 

•  There  are  lessons  learned  (based  on  retrospectives). 

Source:  Palmquist,  Steve,  et  al.  Parallel  Worlds: 
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Traditional  vs  Agile  Approaches  Fit 


Traditional  approach 

•  consistent  with  the  acquisition  life  cycle  guidance  provided  in  the  DoD  Acquisition 
Deskbook  and  its  supporting  documents. 

•  programs  with  stable  requirements  and  environment,  with  known  solutions  to  the 
requirements 

•  programs  with  a  homogeneous  set  of  stakeholders  who  communicate  well  via 
documents 

•  programs  for  which  the  technology  base  is  evolving  slowly  (technology  is  not  expected 
to  be  refreshed/replaced  within  the  timeframe  of  the  initial  development) 

Agile  approach 

•  programs  with  volatile  requirements  and  environment 

•  programs  where  solutions  are  sufficiently  unknown  that  significant  experimentation  is 
likely  to  be  needed 

•  programs  for  which  the  technology  base  is  evolving  rapidly 

•  programs  with  stakeholders  who  can  engage  with  developers  in  ongoing,  close 
collaboration 

Nidiffer,  K.  Miller,  S.  &  Carney,  D.  Potential  Use  of  Agile  Methods  in  Selected  DoD  Acquisitions:  Requirements  Development  and  Management  (CMU/SEI-2013- 
TN-006) 
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Traditional  approach 

Strengths  of  the  traditional  approach  include: 

•  enables  the  comparability  and  repeatability  that  standardization  provides 

•  enables  a  contractually  verifiable  definition  of  completed  intermediate  work 
products 

•  reduces  risks  by  means  of  contractually  assured  baselines 
Weaknesses  of  the  traditional  approach  include: 

•  the  process  drives  measurement  of  compliance  with  itself  as  a  primary 
measure  of  success  (i.e.,  rather  than  measuring  success  as  deploying  a 
workable  solution) 

•  it  depends  on  documents  as  the  basis  to  verify  and  validate  the  requirements, 
the  architecture,  and  the  detailed  design 

•  most  of  the  requirements  are  completed  before  any  code  is  written,  thus 
extending  development  timelines 


Nidiffer,  K.  Miller,  S.  &  Carney,  D.  Potential  Use  of  Agile  Methods  in  Selected  DoD  Acquisitions:  Requirements  Development  and 
Management  (CMU/SEI-201 3-TN-006). 
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Agile  approach 

Strengths  of  this  approach  include 

•  early  insight  by  the  users  into  the  shape  of  the  solution 

•  early  course  correction 

•  “fail  fast”  (If  the  early  solution  ideas  turn  out  to  be  flawed,  little  time  or 
money  is  spent  before  that  learning  occurs.) 

•  explicit  understanding  that  the  requirements  are  expected  to  evolve 

Weaknesses  of  this  approach  (particularly  in  large  acquisition  settings) 
include 

•  more  dependence  on  tacit  knowledge  (e.g.,  lack  of  explicit 
documentation)  as  the  basis  for  decision-making  than  is  comfortable 
for  most  acquisition  organizations 

•  dependence  on  availability  of  actively  engaged  user/customers 

•  difficulty  in  aligning  implementation-driven  artifacts  and  measures  with 
those  of  the  larger  traditional  acquisition  setting. 

Nidiffer,  K.  Miller,  S.  &  Carney,  D.  Potential  Use  of  Agile  Methods  in  Selected  DoD  Acquisitions:  Requirements  Development  and 
Management  (CMU/SEI-201 3-TN-006). 
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Summary 


Interim  DoD  5000.02  (November  2013)  expands  the  explicit  descriptions 
of  life  cycles  expected  to  be  used  in  DoD  acquisitions 

•  Should  make  it  easier  for  programs  interested  in  Agile  methods  to  adopt  them 
within  explicit  5000.02  guidance 

A  Key  Difference  in  Traditional  and  Agile  Approaches 

•  Forward-Looking  Perspective  vs.  Backward-Facing  Perspective 

•  In  a  dynamic  environment  like  the  DoD,  the  Traditional  World  struggles  to 
deliver  as  it  constantly  looks  back  at  long-fixed  requirements  and  priorities. 

•  In  a  dynamic  environment  like  the  DoD,  the  Agile  World  adapts  as  it 
delivers  by  constantly  looking  forward  at  evolving  requirements  and 
priorities. 


=  Software  Engineering  Institute  Carnegie  Mellon  University 


Agile  Myths,  Picatinny  Arsenal 
Lapham,  Wrubel  Jan  2015 
©  2015  Carnegie  Mellon  University. 


51 


COMMON  AGILE  METHODS 
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Methods  Generally  Termed  “Agile” 

Scrum 

•  focused  on  team  management  practices 

XP  (Extreme  Programming) 

•  focused  on  team  technical  practices 

Dynamic  Systems  Development  Method  (DSDM) 

•  Popular  in  UK,  based  on  RAD  (Rapid  Application  Development) 

•  One  of  the  oldest  Agile  methods,  designed  for  large  scale 

Crystal 

•  Encourages  risk-based  selection  of  practices;  different  patterns  for  different  contexts 

Test  Driven  Development  (TDD) 

•  Technical  and  management  practices  focused  on  writing  the  test  that  proves 
acceptance,  then  coding  to  that 

Disciplined  Agile  Delivery  (DAD) 

•  Derived  from  Rational  Unified  Process,  designed  to  scale 

Scaled  Agile  Framework  (SAFe) 

•  Merger  of  lean  and  other  Agile  methods  to  support  large  scale  projects 
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All  Agile  Methods  Share  Most  of  These 
Characteristics 

Iterative  — elements  are  expected  to  move  from  skeletal  to  completely  fleshed 
out  over  time,  not  all  in  one  step 

Incremental  — delivery  doesn’t  occur  all  at  once 

Collaborative  — progress  is  expected  to  be  made  by  stakeholders  and  the 
development  team  working  collaboratively  throughout  the  development  time 
frame 

Parallel  — multiple  self-organizing,  cross-functional  teams  work  concurrently  on 
multiple  product  elements  (e.g.,  requirements,  architecture,  design,  and  the  like 
for  multiple  loosely  coupled  product  components) 

Dedicated  — team  members  are  allowed  to  focus  on  the  tasks  within  an 
iteration/release  as  opposed  to  multi-tasking  across  multiple  projects 

Time-boxed  — relatively  short-duration  development  cycles  that  permit 
changes  in  scope  rather  than  changes  in  delivery  time  frame 


Adapted  from  Nidiffer,  Miller,  &  Carney.  Potential  Use  of  Agile  Methods  in  Selected  DoD  Acquisitions:  Requirements  Development  &  Management,  SEI- 
2013-TN-006 
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Sequential  vs.  overlapping  development 


Reqmts 


Design 


Rather  than  doing  all  of  one 

. . - . — -  ...Scrum  teams  do  a  little 


of  everything  all  the  time 


Source:  “The  New  New  Product  Development  Game”  by 
Takeuchi  and  Nonaka.  Harvard  Business  Review,  January 
1986. 
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Agile  at  Scale-Scaled  Agile  Framework  (SAFe) 

Scaled  Agile  Framework"  Big  Picture 
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Agile  Release  Train  delivers  solutions 


SAFe 

www.scaledagileframework.  com 
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Accounts  for  the 
strategic  business 
layer,  applying  lean 
concepts 

Adapts  Agile  and  lean 
methods  to  deal  with 
program/project  and 
system  issues 


Adds  some  lean 
concepts  to  traditional 
Agile  team  methods  to 
align  team  work  with 
larger  program 
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Agile  at  Scale-DSDM 


DSDM  System  Life  Cycle 


DSDM 

www.dsdm.org 


8  Principles  for  DSDM 

The  eight  Principles  are: 

1.  Focus  on  the  business  need 

2.  Deliver  on  time 

3.  Collaborate 

4.  Never  compromise  quality 

5.  Build  incrementally  from  firm  foundations 

6.  Develop  iteratively 

7.  Communicate  continuously  and  clearly 

8.  Demonstrate  control 

DSDM  Roles  Map  Well  to 
Traditional  Project  Mgmt 
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Agile  at  Scale — Disciplined  Agile  Delivery 


Construction 


Continuous  stream  of  development 

Sufficient  functionality 


* 

J  Production  ready  — J 


Leverages  concepts 
from  Rational  Unified 
Process  and 
designed  to  easily 
align  with  projects 
using  Rational 
Unified  Process 


Risk+value-driven  life 
cycle 


Enterprise  Aware 


Focused  at  project 
level 
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Extreme  Programming  -  Commonly  Used 
Technical  Practices 

User  stories,  used  in  several  Agile  methods,  derive  from  Extreme 
Programming 


Technical  practices  from  XP  commonly  incorporated  into  other  Agile 
methods: 

•  Continuous  integration 

•  Daily  Build/Automated  Regression  Test 


Pair  programming,  another  XP  technical  practice,  is  not  used  as  often 
the  above  outside  of  XP  environments 
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Test  Driven  Development  (TDD) 

Two  common  flavors  of  TDD: 

•  Within  an  iteration,  at  unit/component  level 

•  Acceptance  TDD  -  across  the  life  cycle 


Unit-level  TDD 

•  For  each  requirement/user  story,  a  test  is  written  BEFORE  coding  starts  on 
that  element 

•  The  minimum  amount  of  code  needed  to  pass  the  test  is  written  and 
integrated  into  the  code  base 


Acceptance  TDD 

•  Expands  the  role  of  the  product  backlog  to  include  the  acceptance  tests  that 
will  demonstrate  satisfaction  of  the  requirements 

•  Usually  user  story-based 

•  Cross-functional  teams  collaborate  to  build  the  acceptance  criteria  for  the 
stories/requirements 
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Crystal 

From  A.  Cockburn’s  description  of  Crystal: 

“Crystal  is  a  family  of  human-powered,  adaptive,  ultralight,  “stretch-to- 
fit”  software  development  methodologies. 

•  “Human-powered”  means  that  the  focus  is  on  achieving  project  success 
through  enhancing  the  work  of  the  people  involved  (other  methodologies 
might  be  process-centric,  or  architecture-centric,  or  tool-centric,  but  Crystal  is 
people-centric). 

•  “Ultralight”  means  that  for  whatever  the  project  size  and  priorities,  a  Crystal- 
family  methodology  for  the  project  will  work  to  reduce  the  paperwork, 
overhead  and  bureaucracy  to  the  least  that  is  practical  for  the  parameters  of 
that  project. 

•  “Stretch-to-fit”  means  that  you  start  with  something  just  smaller  than  you  think 
you  need,  and  grow  it  just  enough  to  get  it  the  right  size  for  you  (stretching  is 
easier,  safer  and  more  efficient  than  cutting  away). 

Crystal  is  non-jealous,  meaning  that  a  Crystal  methodology  permits 
substitution  of  similar  elements  from  other  methodology 

Source:  http://alistair.  cockburn.  us/Crystal+methodologies 
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Summary 


The  family  of  Agile  methods  has  grown  in  the  last  12  years 
to  incorporate  methods  that  address  team,  project,  and 
enterprise  levels  of  scaling 

•  It  is  likely  there  will  never  be  a  “single”  Agile  method 


Some  methods  are  seen  more  frequently  in 
regulated/government  settings  than  others 


All  derive  from  the  Agile  tenets  and  principles 


Hybrids  of  multiple  methods  are  common  in  practice  in  both 
industry  and  government 
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Source:  7th  Annual  Survey  on  State  of  Agile,  Version  One 
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SCRUM-THE  MOST  ADOPTED 
AGILE  METHOD 
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Sweet  Spot  for  Scrum 


Key  Elements  of  Scrum 


daily  Scrum 
Meeti  mb 


f - ' 

PRODUCT 

SPRINT 

BACKLOG 

BACKLOG 

24  Hours 


Potentially 
Ship  fable 
PRODUCT 
INCREMENT 


2-4  Weeks 


CDPYRIGHT  W  ZDOSh  MCIIJHTAIN  BOAT  SOFTWARE 


Image  available  at  www.mountaingoatsoftware.com/scrum 
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Scrum  framework 


Roles 


•Product  owner 
•Scrum  Master 
•Team 


Artifacts 


'Product  backlog 
'Sprint  backlog 
'Burndown  charts 


Ceremonies 


•Release  Planning 
•Sprint  planning 
•Sprint  review 
•Sprint  retrospective 
•Daily  scrum  meeting 
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Where  PMO  Generally  Fits  In  a  Scrum 
Implementation 


Copyright  ©  Z005t  Mountain  Boat  Software 


Iterations  are  often  called  “sprints”;  2  week  sprints  are  common 
in  industry;  3-4  week  sprints  are  more  common  in  regulated  settings 


How  do  you  decide  how  long  an  iteration  should  be? 


=  Software  Engineering  Institute 


Carnegie  Mellon  University 


Agile  Myths,  Picatinny  Arsenal 
Lapham,  Wrubel  Jan  2015 
©  2015  Carnegie  Mellon  University. 


Summary 


Scrum  focuses  on  the  team  management  aspects  of  Agile  software 
development 


As  the  most  commonly-practiced  Agile  methodology,  it  is  the  one  that 
most  practitioners  are  familiar  with 


Many  of  the  scaling  approaches  leverage  Scrum  practices  as  the  team 
component  of  their  methodology 


The  Scrum  “Product  Owner”  role  provides  a  proactive  role  for  acquisition 
program  offices  to  collaborate  with  software  teams 
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CHALLENGES  TO  AGILE 
ADOPTION  IN  DOD 
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Comparison  of  Agile  and  Traditional  DoD 
Cultural  Elements., 


Knowledge  Piece 


Method 


Organizational  Structure 


Agile  DoD 

Flexible  and  adaptive  structures 

Self-organizing  teams 

Collocated  teams  or  strong 
communication  mechanisms 
when  teams  are  distributed 


Traditional  DoD 

Formal  structures  that  are 
difficult  to  change 

Hierarchical,  command-and- 
control-based  teams 

Integrated  product  teams  that 
have  formal  responsibilities 


Leadership  Style 


Agile  DoD 

Facilitative  leadership 

Leader  as  champion  and  team 
advocate 


Traditional  DoD 

Leader  as  keeper  of  vision 

Leader  as  primary  source  of 
authority  to  act 


http://www.sei.cmu.edu/library/abstracts/reports/11  tn002.cfm?DCSext.abstractsource=SearchResults 


Agile  Myths,  Picatinny  Arsenal 

Mellon  University  Lapham,  Wrubel  Jan  2015  70 

©  2015  Carnegie  Mellon  University. 


-  Software  Engineering  Institute  Carnegie 


Comparison  of  Agile  and  Traditional  DoD 
Cultural  Elements2 


Knowledge  Piece  I  Method 


Rewards  System 

Agile  DoD 

Traditional  DoD 

•  Team  is  focus  of  reward  systems 

•  Individual  is  focus  of  the 

o  q 

reward  system 

•  Sometimes  team  itself  recognizes 

individuals 

Staffing  Model 

Agile  DoD 

Traditional  DoD 

lOI 

•  Cross-functional  teams  including 

•  Uses  traditional  life-cycle  model 

c 

all  roles  across  the  life  cycle 

with  separate  teams,  particularly 

d 

throughout  the  lifespan  of  the 

for  development  and  testing 

QJ 

project 

•  Different  roles  are  active  at 

•  Includes  an  Agile  advocate  or 

different  defined  points  in  the  life 

coach  who  explicitly  attends  to 

cycle  and  are  not  substantively 

the  team’s  process 

involved  except  at  those  times 
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Comparison  of  Agile  and  Traditional  DoD 
Cultural  Elements3 


Knowledge  Piece 


Method 


Communications  & 
Decision  Making 


Agile  DoD 

•  Daily  stand-up  meetings 

•  Frequent  retrospectives  to  improve 
practices 

•  Information  radiators  to 
communicate  critical  project 
information 

•  Evocative  documents  to  feed 
conversation 

•  “Just  enough”  documentation, 
highly  dependent  on  product 
context 


Traditional  DoD 

•  Top-down  communication 
structures  dominate 

•  External  regulations,  policies  and 
procedures  drive  the  focus  of  work 

•  Indirect  communications,  like 
documented  activities  and 
processes,  dominate  over 
face-to-face  dialogue 

•Traditional,  representational 
documents  used  by  the  PMO 
throughout  the  development  life 
cycle  to  oversee  the  progress  of 
the  developer 


•  PMO  oversight  tools  focused  on 
demonstrating  compliance  vs. 
achieving  insight  into  progress 


http://www.sei.cmu.edu/library/abstracts/reports/11  tn002.cfm?DCSext.abstractsource=SearchResults 
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Exercise 


Break  into  pairs  and  discuss  which  of  the  “Agile  DoD”  cultural  elements 
you  think  are  the  most  difficult  for  your  DoD  setting. 

Be  prepared  to  discuss  your  thoughts  with  the  larger  class. 
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Polling  Question 

How  Big  a  Challenge  is  Your  Adoption  of  Agile  Practices? 

•  Large,  we  need  a  culture  change 

•  Medium,  we  are  running  into  issues 

•  Small,  we  are  mostly  ready 

•  Nonexistent,  no  challenge  at  all 


Level  of  Learning  Required 
Culture 


Years  Months  Weeks 

Time  to 
Adjust 


Small 


Magnitude  of 
Technological 
Change  Sought 


Large 


Culture  Change  is  an  Issue  throughout  Industry 


Ability  to  change 
organizational  culture 


Trying  to  fit  agile 
elements  into  a 
non-agile 
framework 


General  resistance 
to  change 


Management 

support 


Budget 

constraints 


Perceived  time 
to  transition 


Customer 

collaboration 


Availability  of 
personnel 
with  right  skills 


None 


Confidence  in 

ability  to  scale 


Project  complexity 


BARRIERS  TO  FURTHER 
AGILE  ADOPTION 

The.  ho  t-hovingt  the> 
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c-kosvvji  os^vl  hh^'.^qj  ho  Tvh  de^twhs  w\ho 
rorr&vgtfc  "PeJ-t-eAve. A  time.  to 

hn>sV\sAhion  cxnA  WAgth  tjons+i^^ts  WxA  tke, 
louutsh  VnpAt+  ov\  ?urhV\e_f-  (K.Ao'ptson- 
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Agile  klade  Easier 


VERSIONONE  COM 

Source:  7th  Annual  Survey  on  State  of  Agile,  Version  One 


=  Software  Engineering  Institute  Carnegie  Mellon  University 


Agile  Myths,  Picatinny  Arsenal 
Lapham,  Wrubel  Jan  2015 
©  2015  Carnegie  Mellon  University. 


75 


Agile  Software  Development 


Reasons  for  Failure 

Paths  to  Success 

Inadequate  oversight 

Working  shoulder  to  shoulder  for 
PMOs  and  developers 

Inadequate  requirements 
management 

Continuous  involvement  of  users  and 
other  stakeholders,  paying  attention 
to  end-to-end  capability 

Inadequate  design  and 
architecture 

Integrated  design,  implementation  and 
integration  cycles  on  top  of  an 
infrastructure  enabling  agility 

Inadequate  documentation 

Consolidated  documentation  forms 
that  minimize  redundancy 

Artifacts  that  enhance 
communication  and  maintainability 
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Patriot  Excalibur:  An  Agile  Success  Story  in 
DoD 
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Industry  Lessons  Learned 

BEST  'LESSONS  LEARNED' 


Many  of  the  lessons 
learned  in  commercial 
industry  for  Agile  adoption 
can  apply  in  DoD  settings 


Source:  7th  Annual  Survey  on  State  of  Agile,  Version  One 
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Suggesting  Successful  Approaches 


Educating  leadership  and  staff  on  differences  they  will  see 

Reminding  organizations  of  the  typical  challenges  they  face  for  a  big 
change 

Disseminating  successful  approaches  when  we  find  them 


Adding  in  a  little  humor  along 
the  way... 


'ft*  kyU-  i 

f***/  *>  ? 

f'  -I****, 
******  ^ 
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Help  People  Understand  What’s  Coming 


GIVING  A  CLEfcR 

IDEA  AfcotfT  NOW  THt  £dL£^ 
CHANGE.  WIU-  (OSWMX/j  RCDliCH 
FEAR oT THE  UNKNOWN) 
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A  Few  Things  to  Think  About  When  People 
Cite  “Regulations”  as  a  Reason  *Not*  to 
Embrace  Agile  Approaches 

Who  are  the  real  stakeholders?  Where  are  the  political  “bodies”  buried? 
How  do  the  “ghosts”  in  the  stakeholder  map  affect  what  people  do 
today? 


Yo<Jk  Host 

VALUABLE- 

thinking 

OlFrfctftKTLT 


Value  stream  mapping,  a  lean  technique,  is  sometimes  useful  to  point 
out  waste  areas  where  Agile  could  help,  in  an  organization  that  is  trying 
to  reduce  cost  by  eliminating  wasted  effort 


When  analyzing  processes  currently  in  use,  always  ask  “For  whom?” 
and  “So  what?”  (ask  them  about  your  Agile  practices  too!!) 


Most  regulated  environments  involve  conflicting  mandates:  different 
people  choose  different  areas  to  emphasize — try  to  find  the  ones  most 
complementary  to  Agile  approaches  and  focus  on  those 


Caution:  Burning  Platform  Approach  to  New 
Practice  Adoption 


It  can  work,  but 
there  are  lots  of 
challenges. 


\ 

CM  f  I*  ft, 


lqineering  Institute 
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“Traditional”  Adoption  Tools  and  Methods 
Work  Well  with  Agile  Adoption 


Understand  the  Change  Cycle  and 
Your  Adoption  Population 


Innovators 

Late 

Early 

Early  MaJorlt^ 

Adopters  Majority  Laggards 


Prepare  for  Both  Communication 
and  Implementation  Support 
Mechanisms  that  are  Needed 
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Exercise 

Break  into  pairs  and  discuss  communication  and  implementation 
mechanisms  you  think  will  be  necessary  to  adopt  (or  were  missing,  if  you’ve 
already  adopted)  Agile  methods  in  your  setting.  Mark  them  with  the  initial  of 
which  stage  of  the  Adoption  Commitment  Curve  you  believe  they  address. 

Be  prepared  to  discuss  your  thoughts  with  the  larger  class. 

Communication  Mechanisms  Implementation  Mechanisms 

•  C=Contact/Awareness  •  TU=Trial  Use 

•  U=Understanding  •  A=Limited  Adoption 

•  l=lnstitutionalization 
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Understanding  Your  Readiness  for  Agile 
Adoption 


General  cultural  analyses  for  adoption  of 
Agile  methods  don’t  tend  to  pick  up  some  of 
the  acquisition  issues  inherent  in  these 
environments. 

SEI  Readiness  &  Fit  Analysis  (RFA)  and  its 
underlying  model  explicitly  include  risk  areas 
known  to  impede  Agile  adoption  in  regulated 
environments 

•  More  emphasis  on  business  models,  goal 
alignment,  and  acquisition  strategy 

•  More  focus  on  alignment  issues — 
especially  related  to  staff  turnover 

•  Some  particular  issues  around  interfacing 
with  systems  engineering  in  large 
systems  developments 
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Summary 


Agile  RFA  Categories 


•Business  and  acquisition  — adoption  factors 
related  to  business  strategy,  acquisition  strategy, 
and  contracting  mechanisms 

•Organizational  climate  -  adoption  factors 
related  to  sponsorship,  leadership,  reward 
systems,  values,  and  similar  “soft”  issues 

•System  attributes  -  adoption  factors  related  to 
the  actual  characteristics  of  the  system(s)  being 
developed 

•Project  and  customer  environment  - 

adoption  factors  related  to  project  management 
norms,  team  dynamics  and  support  structures, 
and  customer  relationships  and  expectations 

•Technology  environment  -  adoption  factors  ^ 
related  to  the  technologies  that  are  in  place  or 
planned  to  support  the  selected  Agile  methods 


•Practices  -  a  taxonomy  of  Agile  practices 
commonly  adopted  within  DoD  that  is  used  to 
understand  which  practices  an  organization 
plans  to  adopt  so  that  other  factors  can  be 
calibrated  around  those  expectations 


Rating  of  3  indicates  some  issues  likely,  but  nothing  unusual 
for  an  Agile  adoption.  Below  3  indicates  issues  that  will 
negatively  impact  adoption  success.  Above  3  indicates  issues 
that  could  enable  adoption  success. 

More  important  than  the  rating  is  the  specific  risks  that 
RFA  participants  identify. 


=  Software  Engineering  Institute  Carnegie  Mellon  University 


Agile  Myths,  Picatinny  Arsenal 
Lapham,  Wrubel  Jan  2015 
©  2015  Carnegie  Mellon  University. 


87 


Business  &  Acquisition  Category  Particularly 
Affects  DoD  Agile  Adoption 


Business  or  Program  goals  are  clear  and 
reflect  stakeholders  concerns 

Success  strategies  (e.g.  roadmaps,  product 
portfolios)  are  defined  and  clearly 
communicated 

Funding  for  the  project  has  been  secured 

Mechanisms  are  in  place  in  the  contract  and 
acquisition  strategy  to  allow  close  collaboration 
between  developers  and  end  users 

Mechanisms  are  in  place  in  the  contract  and 
acquisition  strategy  that  allow  for  interim 
demonstration  and  delivery  between  official 
releases 


Business/Acquisition  Factors 


Contract  oversight  mechanisms  are  aligned  with  agile  principles 

The  alignment  of  software-related  goals  with  program-level  goals  is  clear 

Contract  type  accounts  for  use  of  agile/lean  methods  in  the  program 

Life  cycle  activities  are  planned  in  the  acquisition  strategy  that  are  compatible  with  agile/lean 
methods 


Acquisition  strategy  takes  into  account  the  use  of  agile  methods  at  the  scale  needed  for  the  program 
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SEI’s  Agile  RFA  Application  So  Far 


Agile  RFA  has  been  applied  by  the  SEI  in  2  DoD  and  1  Federal  Agency 
setting 

•  Case  1  was  a  military  program  considering  adopting  Agile  methods 

-  They  identified  areas  to  address  to  improve  their  chance  of  success 

•  Case  2  was  a  military  program  already  adopting  Agile  methods 

-  They  identified  the  source  of  symptoms  they  were  aware  of 

-  They  also  identified  disconnects  between  management  and  practitioner 
views  of  what  was  going  on 

-  They  used  RFA  to  help  them  monitor  adoption  progress  and  systematically 
reduce  probability  and  impact  of  adoption  risks 

•  Case  3  was  a  federal  agency  who  was  mandated  to  adopt  Agile  methods 

-  They  identified  areas  to  work  on  before  starting  Agile  pilots 

-  They  used  RFA  to  help  them  monitor  adoption  progress 
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Summary 


Adopting  Agile  methods  involves  (sometimes  significant)  cultural  shifts 
as  well  as  practice  changes 

•  Transition  and  adoption  approaches  for  other  major  organizational  changes 
will  work  for  Agile  adoption  as  well 

•  Go  in  with  your  eyes  open — Readiness  &  Fit  Analysis  or  other  methods  of 
assessing  readiness  can  help  you  to  avoid  pitfalls  as  you  approach  adoption 

•  Many  adoption  support  mechanisms  exist  out  in  the  commercial  world  that 
can  be  adapted  to  regulated  settings 

-  There  are  even  training  courses  geared  toward  government  settings 
becoming  available 

-  The  SEI  Technical  Notes  and  other  resources  (blogs,  podcasts,  etc)  on 
Agile  adoption  are  meant  to  support  acquisition  practitioners  in  becoming 
knowledgeable  about  different  issues  they  may  encounter  when  adopting 
Agile  or  lean  methods 
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Agile  Myths— BUSTED! 


Remember?  Jamie  and  I  testing  Killer  Washing  Machine.  One  of  the  few  where 
NOTHING  was  true.  -  Adam  (@DontT lyThis) 


Image  Credit:  DCt 
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Remember... Agile  is  Not  a  Silver  Bullet 
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Call  to  Action 


If  the  things  we  have  discussed  resonate  with  you 

•  Read  some  of  our  papers/presentations  to  get  ideas 

-  Every  Technical  Note  represents  inputs  from  dozens  of  people 
actively  working  in  adopting  Agile  methods  in  a  DoD  or  federal  setting 

•  See  where  strategies  that  have  worked  in  other  parts  of  the  DoD  might 
apply  to  you 

-  Look  for  places  from  our  work  where  you  have  faced  similar 
situations 

-  If  you  have  a  success  strategy  you  don’t  see  us  promulgating,  please 
consider  sharing  with  us!  We’re  here  to  learn! 

•  Consider  joining  our  Agile  Collaboration  Group 

-Over  125  members  from  all  military  services,  contractors,  federal 
agencies  who  help  us  focus  our  research  and  share  their 
experiences 

•  Send  email  to  Mary  Ann  Lapham,  mlapham@sei.cmu.edu 
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Contact  Information 

Mary  Ann  Lapham 

Principal  Engineer 
Client  Technical  Solutions 
Email:  mlapham@sei.cmu.edu 

Eileen  Wrubel 

Client  Technical  Solutions 
Email:  eow@sei.cmu.edu 


U.S.  Mail 

Software  Engineering  Institute 
Customer  Relations 
4500  Fifth  Avenue 
Pittsburgh,  PA  15213-2612 
USA 

Web 

www.sei.cmu.edu/acquisition/research 

Customer  Relations 

Email:  info@sei.cmu.edu 

SEI  Phone:  +1  412-268-5800 

SEI  Fax:  +1  412-268-6257 
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Gimmes  &  Gotchas 

Gimmes  are  a  list  of  behaviors  that  give 
you  confidence  that  your  program  office, 
organic  development  organization,  and/or 
contractor  is  embracing  an  agile  process. 

Gotchas  are  a  list  of  behaviors  that  may 
indicate  problems  currently  exist  or  are  on  the 
horizon  in  your  agile  program. 

These  Gimmes  &  Gotchas  are  not  intended  to  be  all  inclusive, 
nor  are  they  a  checklist.  The  goal  of  these  is  to  help  identify 
areas  to  investigate  further  and  focus  your  energy  toward  a 
successful  program. 
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Steps  Gimmes  1 


•  Your  program  office,  organic  development  teams,  and 
contractors  understand  the  system  is  software-reliant 

•  Your  motivation,  trade-offs,  benefits,  and  expectations  for 
using  an  agile  approach  is  clearly  documented  and 
understood 

•  There  is  an  explicit  understanding  that  the  requirements 
are  expected  to  evolve 

•  Automated  testing  is  planned  for  and  budgeted 

•  Multiple  acquisition  approaches  are  being  considered 


Italics  -  this  item  also  impacts  external  stakeholders 
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Steps  Gimmes  2 


•  Contract/MOA  allows  flexibility  and  incremental  delivery 

•  The  concept  of  incremental  delivery  of  content  is  included 
in  CDRLs  or  MOA  terms 

•  Entire  program  team  is  aware  that  the  DoD  5000.02  has 
two  new  lifecycle  descriptions  that  support  more  "agile" 
approaches 

•  Hindrances  for  agile  implementation  are  acknowledged 
and  paths  to  success  are  identified 

•  Readiness  for  agile  adoption  is  determined  by  using  a 
formal  method  such  as  the  SEI  Readiness  and  Fit 
Analysis  (RFA) 
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Steps  Gotchas 


Gotcha! 


•  Senior  managers  and  stakeholders  reluctantly  agreed  to 
use  agile  or  are  unaware 

•  Software  development  is  constrained  to  a  hardware 
architecture 

•  Mindset  that  document  completion  equals  progress 

•  Program  exists  in  a  "risk  averse  culture" 

•  Integration  testing  isn't  planned  until  just  before  final 
delivery 

•  Testing  isn't  budgeted  until  much  later  in  the  program 

•  Agile  is  being  considered  a  silver  bullet 

Italics  -  this  item  also  impacts  external  stakeholders 
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Readiness  Gimmes  1 


•  Your  agile  approach  has  been  tailored  to  best  meet  your 
program's  needs 


•  Program  office  staff  and  organic  development  team, 
including  systems  engineers,  understand  the  agile 
process  you're  using 


•  The  agile  manifesto  and  principles  are  understood 
throughout  the  organization 


•  Appropriate  training  has  been  provided  for  the  entire 
organization 


•  Expectations  and  artifacts  necessary  for  milestone 
decisions  have  been  agreed  to  and  documented 


Italics  -  this  item  also  impacts  external  stakeholders 
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Readiness  Gimmes  2 


•  Agile  roles  and  responsibilities  have  been  clearly 
assigned 


•  The  definition  of  done  has  been  established  and  includes 
what  documentation  is  required 


•  The  contracting  team  has  been  trained  and  understands 
the  agile  process 

•  The  program  office  is  open  to  changing  roles 

•  Systems  engineers  are  an  integral  part  of  the  agile 
process 


Italics  -  this  item  also  impacts  external  stakeholders 
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Readiness  Gimmes  3 


•  The  schedule  identifies  when  emulators/simulators  are 
needed  by  the  software  development  team 


•  Leadership  and  staff  are  educated  on  differences  from 
the  way  they  are  used  to  doing  business 


•  Program  team/organic  development  team  has  answers 
for  most  agile  "myths" 


•  Program/organic  development  team  utilizes  adoption 
support  mechanisms,  e.g.  coaching/training,  facility 
configuration  that  supports  information  radiators,  industry 
blogs/publications,  etc. 
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Readiness  Gotchas 


Gotcha! 


•  Your  testing  function/organization  has  not  been 
integrated  into  the  day-to-day  activities 

•  Requirements  stability,  operating  environment,  and  the 
evolution  of  the  technology  base  has  not  been  fully 
assessed 

•  Constraints  are  imposed  for  the  sake  of  tradition 

•  Contract  progress  payments  are  based  on  "earned  value " 
for  the  accounting  period 

•  Testing  organization  is  not  involved  in  the  agile  process 

•  Regulations  are  cited  as  a  reason  not  to  embrace  agile 
approaches 

Italics  -  this  item  also  impacts  external  stakeholders 


Application  Gimmes  1 


•  Your  users  and  stakeholders  can  accommodate 
incremental  deliveries 


•  Necessary  and  beneficial  documentation  has  been 
identified 


•  Requirements  can  be  prioritized  without  pushback 

•  User  stories  conform  to  the  “INVEST”*  concept 

•  Technical  reviews  are  structured  to  understand  technical 
issues  and  mitigate  technical  risks 


INVEST  =  Independent,  Negotiable,  Valuable,  Estimable,  Small,  Testable 
Italics  -  this  item  also  impacts  external  stakeholders 
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Application  Gimmes  2 


•  Iteration  and  release  reviews  are  used  to  build  a  case  to 
demonstrate  readiness  to  pass  milestone  reviews 


•  Agile  measurements  are  integrated  into  your  overall 
management  metrics 

•  Measurements  are  focused  on  “are  we  producing 
sufficient  value  fast  enough?” 

•  User  requirements  are  validated  during  the  creation  of 
user  stories 


•  The  program  office  responsibilities  haven't  changed  but 
how  they  perform  them  has 


Italics  -  this  item  also  impacts  external  stakeholders 
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Application  Gotchas 

•  Your  program  or  contractor  is  proposing  agile  as  a  quick 
fix  for  existing  failures  on  the  program 

•  Team  metrics  (e.g.,  velocity)  are  used  for  comparisons* 

•  Users  and  stakeholders  are  not  actively  engaged  in  the 
agile  process 

•  Oversight  activities  are  abandoned 

•  Focus  is  on  compliance  rather  than  mission  success 


*Team  composition  varies,  so  relative  measures  like  velocity  apply  only 
within  a  team,  not  between  multiple  teams. 

Italics  -  this  item  also  impacts  external  stakeholders 
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Selected  SEI  Agile  Publications., 

Papers 


Agile  Methods  in  Air  Force  Sustainment:  Status  and  Outlook  (CMU/SEI-2014-TN-009) 

http://resources.sei.cmu.edu/librarv/asset-view.cfm?assetid=312754 

Considerations  for  Using  Agile  in  DoD  Acquisition  (CMU/SEI  2010-TN-002) 

http://resources.sei.cmu.edu/asset  files/TechnicalNote/2014  004  001  312766.pdf 


Agile  Methods:  Selected  DoD  Management  and  Acquisition  Concerns  (CMU/SEI-2011-TN-002) 

http://www.sei.cmu.edU/librarv/abstracts/reports/1 1tn002.cfm?DCSext.abstractsource=SearchResults 


Agile  Metrics:  Progress  Monitoring  of  Agile  Contractors  (CMU/SEI-2013-TN-029) 

http://resources.sei.cmu.edu/librarv/asset-view.cfm?assetid=77747 


A  Closer  Look  at  804:  A  Summary  of  Considerations  for  DoD  Program  Managers  (CMU/SEI-2011-SR-015) 

http://www.sei.cmu.edU/librarv/abstracts/reports/1  IsrOI  5.  cfm?DCSext.abstractsource=SearchResults 


DoD  Information  Assurance  and  Agile:  Challenges  and  Recommendations  Gathered  Through  Interviews  with 
Agile  Program  Managers  and  DoD  Accreditation  Reviewers  (CMU/SEI  2012-TN-024) 

http://resources.sei.cmu.edu/librarv/asset-view.cfm?assetid=34083 


Agile  Software  Teams:  How  They  Engage  with  Systems  Engineering  on  DoD  Acquisition  Programs  (CMU/SEI- 
2014-TN-013) 

http://resources.sei.cmu.edu/librarv/asset-view.cfm?assetid=295943 
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Selected  SEI  Agile  Publications2 


Papers,  cont. 


Parallel  Worlds:  Agile  and  Waterfall  Differences  and  Similarities  (CMU/SEI-2013-TN-021) 

http://resources.sei.cmu.edu/librarv/asset-view.cfm?assetid=62901 


Potential  Use  of  Agile  Methods  in  Selected  DoD  Acquisitions:  Requirements  Development  and  Management 
(CMU/SEI-201 3-TN-006) 

http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=89158 


DoD  Agile  Adoption:  Necessary  Considerations,  Concerns,  and  Changes 

http://www.crosstalkonline.org/issues/ianfeb-2012.html 


Colloquium 

SEI  Agile  Colloquiums,  June  20-21 , 2012;  March  19-20,  2013,  July  16-17,  2013,  June  5,  2014 


Colloquium  Graphic  Recording  (available  upon  request) 


Webinar 

Agile  Research  Forum,  Agile  Methods:  Tools,  Techniques,  and  Practices  for  the  DoD  Community,  Mary  Ann  Lapham, 
August  2012 

http://www.sei.cmu.edu/qo/aqile-research-forum/ 
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Selected  SEI  Agile  Publications3 

Blogs 

Readiness  and  Fit  Analysis  (October  8  2012) 
http://bloq.sei.cmu.edu/archives.cfm/author/suzanne-miller 

Agile  Methods:  Tools,  Techniques,  and  Practices  for  the  DoD  Community 

http://bloq.sei.cmu.edu/post.cfm/aqile-methods-tools-techniques-and-practices-for-the-dod-communitv 

Using  Agile  Effectively  in  DoD  Environments  (February  6,  2012) 
http://bloq.sei.cmu.edu/archives.cfm/author/marv-ann-lapham 

Podcast 

Agile  Acquisition  (September  4,  2012) 

http://www.sei.  cmu.edu/podcasts/index.cfm?qetRecord=7D03CB1  F-9D60-C314- 

66526F8E8B2864B8&wtPodcast=AqileAcquisition 

DoD  and  Agile  Principles  Series 

http://www.sei.cmu.edu/podcasts/aqile-in-the-dod/index.cfm 

Want  More? 

For  additional  SEI  papers,  blogs,  and  podcasts  on  Agile,  please  visit  the  SEI  Digital  Library  at 

http://resources.sei.cmu.edu/librarv/results.cfm7as  q=inmeta:qsataxonomvoutput~Aqile 

We  regularly  publish  new  materials!  Check  back  often! _ 
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Selected  SEI  Agile  Publications4 


Selected  Conferences 

•  NDIA  Systems  Engineering  Conference  October  25-28,  2010 

-  Presentation:  Using  Agile  in  DoD  Acquisition 

•  Systems  and  Software  Technology  Conference,  May  16-19,  2011 

-  Presentation:  Finding  Discipline  in  an  Agile  Acquisition  Process 

•  Systems  and  Software  Technology  Conference,  April  23  -26,  2012 

-  Opportunities  for  New  Acquisition  Practices:  804  responses 

•  Pacific  NW  Quality  Conference,  Oct  2012 

-  Presentation:  SW  Development  &  Test  as  a  Service:  How  and  Why 

-  Workshop  1 :  SW  Development  &  Test  as  a  Service:  A  Natural  Path  from 
Agile 

-  Workshop  2:  SW  Development  &  Test  as  a  Service:  Adoption  Tips 

•  Agile  East  2012,  Nov  2012 

-  Presentation:  Ready  and  Fit:  Adopting  Agile  in  Constrained  Environments 
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Agile  Myths  References 

Version  One.  “Five  Myths  of  Agile  Development”,  2010. 
http://pm.versionone.com/whitepaper  5myths.html 


“Summary  of  Agile  Myths”,  http://stackoverflow.com/questions/1871 1 10/agile- 
myths-and-misconceptions 


Japikse,  P.  “Top  30  Agile  Myths-Busted”.  Telerik  Team  Pulse. 
http://www.telerik.com/documents/team-productivitv-tools/Top30-AgileMvths- 

Busted.pdf 


Agile  Connection.  “Top  12  Agile  Myths”. 

http://www.agileconnection.com/article/top-twelve-myths-agile-development 


Loffler,  M.  “7  Agile  Myths”,  http://blog.scrumphony.com/2012/06/7-agile-mvths/ 
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PMI  Agile  Recommended  Reading 


The  Program  Management  Institute  has  started  an  Agile 
certification  program.  The  following  is  the  institute’s  2013 
list  of  references: 

Agile  Retrospectives:  Making  Good  Teams  Great 
Esther  Derby,  Diana  Larsen,  Ken  Schwaber 
ISBN  #0977616649 

Agile  Software  Development:  The  Cooperative  Game  - 
Second  Edition 
Alistair  Cockburn 
ISBN  #03214827 

The  Software  Project  Manager’s  Bridge  to  Agility 
Michele  Sliger,  Stacia  Broderick 
ISBN  #0321502752 

Coaching  Agile  Teams 
Lyssa  Adkins 
ISBN  #0321637704 

Agile  Project  Management:  Creating  Innovative  Products 
-  Second  Edition 
Jim  Highsmith 
ISBN  #0321658396 

Becoming  Agile:  ...In  an  Imperfect  World 
Greg  Smith,  Ahmed  Sidky 
ISBN  #1933988258 


Agile  Estimating  and  Planning 

Mike  Cohn 

ISBN  #0131479415 

The  Art  of  Agile  Development 
James  Shore 
ISBN  #0596527675 

User  Stories  Applied:  For  Agile  Software  Development 

Mike  Cohn 

ISBN  #0321205685 

Agile  Project  Management  with  Scrum 
Ken  Schwaber 
ISBN  #073561 993X 

Lean-Agile  Software  Development:  Achieving 
Enterprise  Agility 

Alan  Shalloway,  Guy  Beaver,  James  R.  Trott 
ISBN  #0321532899 

See  www.pmi.org/Certifcation/New-PMI-Aqile- 

Certifcation.aspx  for  updated  information. 
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Other  Resources  used  in  this  briefing 


Slides  16,  39: 

Source:  Dr.  Paul  D.  Nielsen  Director  and  Chief  Executive  Officer  of  the  Software  Engineering  Institute  (SEI),  Carnegie  Mellon 

Before  the  United  States  House  of  Representatives  Defense  Acquisition  Reform  Panel  of  the  Committee  on  Armed 
Services.  July  9,  2009.  8:00  a.m. 

http://democrats.armedservices.house.gov/index.cfm/files/serve7File  id=a7a6c258-de85-430c-97f1-a016893b68c7 

Slidses  16,  39: 

http://www.zdnet.com/blog/projectfailures/10-reasons-for-it-failure/730 
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